Problem

IVR (Interactive Voice Response) navigation is one of the primary use cases for voice agents using send_dtmf_events. In this context, after pressing digits the agent has no meaningful action to take — it must stay silent and listen for the IVR's next prompt. This is not a preference, it is the required protocol: speaking or taking further action before the IVR responds will confuse the system and break the call flow.

However, because send_dtmf_events returns a success string, the LLM receives a tool result and is immediately re-invoked to generate a response. This causes the agent to speak, narrate, or call additional tools before the IVR has had a chance to react to the keypress.

The only way to work around this today is to define a separate no-op tool (e.g. listen_and_wait) that raises StopResponse, then hardcode in the system prompt that it must be called after every single send_dtmf_events invocation. This is unnecessary boilerplate that every IVR agent developer must rediscover and add independently — and it is easy to forget, causing silent, hard-to-debug failures.

Fix

StopResponse is the idiomatic LiveKit Agents mechanism to signal that a tool has completed its work and the agent should yield the turn without generating a response. Raising it at the end of send_dtmf_events encodes the correct behavior directly in the tool, so developers get the right semantics automatically without any prompt engineering or extra tools. The error path still returns a descriptive string so the LLM can be aware of failures and decide whether to retry.

Impact

• Breaking: the tool no longer returns a success string on the happy path. Agents that inspect the return value of send_dtmf_events will need to be updated (no known first-party usage of the return value).
• No changes to the public API surface; StopResponse is already exported from livekit.agents.